Skip to content

Support JS libraries self-registering their exports with visibility attributes - #27436

Merged
sbc100 merged 7 commits into
emscripten-core:mainfrom
guybedford:jslib-exported-functions
Aug 5, 2026
Merged

Support JS libraries self-registering their exports with visibility attributes#27436
sbc100 merged 7 commits into
emscripten-core:mainfrom
guybedford:jslib-exported-functions

Conversation

@guybedford

@guybedford guybedford commented Jul 28, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

This implements support for JS libraries declaring their own public exports using per-symbol attributes, split out from #27208 as requested in review there.

The attributes separate symbol inclusion from export visibility:

  • __export: true exports the symbol if it is otherwise included.
  • __force: true includes the symbol even when nothing references it, without exporting it, analogous to DEFAULT_LIBRARY_FUNCS_TO_INCLUDE.
  • Using both unconditionally includes and exports the symbol.

This allows binding layers such as wasm-bindgen to define a public JS API surface distinct from the wasm export names, including exported classes and namespaces:

addToLibrary({
  $Counter__export: true,
  $Counter__force: true,
  $Counter: class Counter { /* ... */ },
});

The attributes are consumed as JS library compile-time metadata and do not appear in generated output. The JS compiler forwards only the symbols actually emitted through extraExports, allowing the WASM_ESM_INTEGRATION wrapper to re-export them without mutating or returning the global EXPORTED_FUNCTIONS setting. Decorated exports are also retained through meta-DCE.

Test coverage verifies the independent attribute semantics under legacy modularized output, MODULARIZE=instance, WASM_ESM_INTEGRATION, and optimized -O3 builds, together with decorator validation.

Made with AI assistance under my review

@guybedford guybedford mentioned this pull request Jul 28, 2026
Open
@sbc100

sbc100 commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

I think supporting something like this is a great idea but maybe we can bikeshed the design a little.

How about limiting this to symbols actually defined in the JS library itself using symbol attributes. Perhaps something like:

myLibrary = {
   foo: 42,
   foo__export: true,  // Export this symbol outside the module
   foo__alwasyInclude: true, // Include this symbol in the generated code, even if no other code depends on it.
}

I don't love the alwasyInclude name.. perhaps force?

In this scenario it would be possible to specify one of these without that other.

If you specified __export without __force then them symbol would be exported, but only if it was included for some reason.

If you specified __force without __export then the symbol would be included in the generated JS but not exported (similar to (similar to DEFAULT_LIBRARY_FUNCS_TO_INCLUDE).

I would hope that the information could all stay on the JS side, but if it needs to be plumbed back to python then it could then just be small extraExports list perhaps?

@guybedford

guybedford commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

I've updated this following the suggestion here for JS libraries to use the __export and __force symbol attributes:

  • __export: export only when otherwise included
  • __force: always include without exporting
  • both: always include and export

The attributes are compile-time metadata and are not emitted. We no longer mutate or forward EXPORTED_FUNCTIONS, only actually emitted exports are returned as extraExports for the ESM wrapper.

Coverage includes legacy modules, instance ESM, WASM_ESM_INTEGRATION, and O3/meta-DCE.

sbc100
sbc100 reviewed Aug 5, 2026
View reviewed changes

@sbc100 sbc100 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking much better now! Thanks for being flexible.

Comment thread src/jsifier.mjs Outdated
Comment thread src/jsifier.mjs Outdated
Comment thread src/modules.mjs Outdated
@guybedford guybedford changed the title Support JS libraries self-registering their exports via EXPORTED_FUNCTIONS Support JS libraries self-registering their exports with visibility attributes Aug 5, 2026
sbc100
sbc100 reviewed Aug 5, 2026
View reviewed changes
Comment thread src/jsifier.mjs Outdated
sbc100
sbc100 reviewed Aug 5, 2026
View reviewed changes
Comment thread test/test_jslib.py
sbc100
sbc100 reviewed Aug 5, 2026
View reviewed changes

@sbc100 sbc100 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm % comment.

Can you add a ChangeLog entry for this?

@guybedford
guybedford force-pushed the jslib-exported-functions branch from 281ec85 to bc3d67c Compare August 5, 2026 20:18
@guybedford

guybedford commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

Changelog added now as well.

@guybedford guybedford mentioned this pull request Aug 5, 2026
Merged
@sbc100

sbc100 commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

6.0.6 is about to be released in next few minutes/hours, so maybe we hold off landing this until after that happens in order to avoid having to move the changelog entry. See emscripten-core/emsdk#1774

@sbc100

sbc100 commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

OK, 6.0.6 is now releases. Please rebase.

@guybedford
Support JS libraries self-registering their exports via EXPORTED_FUNC…
6eb0984 
…TIONS

JS library code can already mutate the compile-time EXPORTED_FUNCTIONS set
at library load time, which under MODULARIZE=instance causes jsifier to emit
the symbol with an `export` declaration. This makes that flow fully work by
forwarding the final EXPORTED_FUNCTIONS set back from the JS compiler so the
linker can derive which JS library symbols were exported, and have the
WASM_ESM_INTEGRATION wrapper re-export them.

This is used by binding layers (e.g. wasm-bindgen) that define a public JS
API surface distinct from the wasm export names, registering it from their
generated JS library.
@guybedford
Retrigger CI
40cadd9
@guybedford
Use symbol attributes for JS library exports
cbe38b1
@guybedford
Address JS library export review feedback
abe7b92
@guybedford
Process forced library symbols during merge
9accea3
@guybedford
Test JS library export decorators by default
8165f40
@guybedford
guybedford force-pushed the jslib-exported-functions branch from bc3d67c to ab22aee Compare August 5, 2026 22:12
@guybedford

guybedford commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

Ok the Changelog entry is now updated to 6.0.7.

sbc100
sbc100 reviewed Aug 5, 2026
View reviewed changes
Comment thread ChangeLog.md Outdated
@guybedford
guybedford force-pushed the jslib-exported-functions branch from ab22aee to d1fb203 Compare August 5, 2026 22:31
@sbc100
sbc100 enabled auto-merge (squash) August 5, 2026 23:12
@sbc100
sbc100 merged commit 0134648 into emscripten-core:main Aug 5, 2026
45 checks passed
@guybedford
guybedford deleted the jslib-exported-functions branch August 6, 2026 17:26
guybedford added a commit to guybedford/emscripten that referenced this pull request Aug 7, 2026
@guybedford
Unify wasm-bindgen output under -sWASM_BINDGEN, add -sWASM_BINDGEN=auto
bcd31f8 
wasm-bindgen (wasm-bindgen/wasm-bindgen#5210, updated for the __export/
__force symbol attributes from emscripten-core#27436 in wasm-bindgen/wasm-bindgen#5253)
hoists the clean exported API (functions, classes, enums) into top-level
library symbols that self-register as exports via its `--js-library`.
The user-facing API now comes from wasm-bindgen's library in every flow,
so emscripten no longer needs to guess or own the export set.

This collapses the previous staticlib-only handling into a single
-sWASM_BINDGEN path that works whether cargo/rustc drives the link (bin
crate, emcc as the linker, rustc supplies -sEXPORTED_FUNCTIONS) or emcc
drives it (staticlib, exports discovered locally):

- The exports the wasm-bindgen expansion reaches by name - the supplied
  EXPORTED_FUNCTIONS (method shims, the __wbindgen_* runtime, the marker,
  main) plus anything its expansion adds - are internal glue, not a user
  API. They are captured and kept off every export layer: the ESM wrapper
  (user_requested_exports), the factory Module attachment
  (EXPORTED_FUNCTIONS, via should_export), and the keepalive pass in
  finalize_wasm. `main` still runs automatically on init; `_main` isn't
  surfaced.
- A genuine EMSCRIPTEN_KEEPALIVE C/C++ export is not in that internal set
  and remains surfaced, so a hand-written native export composes with
  wasm-bindgen's API in the same module. Human-supplied EXPORTED_FUNCTIONS
  are not preserved through wasm-bindgen linkage yet (the rustc-supplied
  set is indistinguishable from glue); that can be revisited later.
- Strip the placeholder symbols wasm-bindgen consumes
  (__wbindgen_describe*, __externref_*, ...) so they aren't reported as
  undefined exports.
- Only run nm-based export discovery for explicit -sWASM_BINDGEN when no
  driver supplied EXPORTED_FUNCTIONS; the rustc-driven link already lists
  them exactly.
- Wire imported JS: feed library_bindgen.extern-pre.js as extern-pre-js
  and copy the snippets/ dir next to the output so relative imports
  resolve.
- The WASM_ESM_INTEGRATION wrapper re-exports the JS library symbols that
  were exported (MODULARIZE=instance), and provides wasmExports via a
  namespace import of the wasm so by-name export access works.

Add -sWASM_BINDGEN=auto: run wasm-bindgen only when the linked wasm
carries wasm-bindgen's __wasm_bindgen_emscripten_marker custom section,
which is how cargo/rustc opts in when driving emcc as the linker
(addressing the request to replace implicit marker detection with an
explicit flag); otherwise it is a no-op and wasm-bindgen need not be
installed.

Both output modes then expose only the clean API (e.g. a `Greeter`
class). Add an end-to-end test parameterized over the ESM and factory
output modes (built via cargo with -sWASM_BINDGEN=auto), a no-marker
test asserting auto is a no-op for an ordinary build, extend the
staticlib integration test to assert an EMSCRIPTEN_KEEPALIVE export
survives alongside the wasm-bindgen API, and install a pinned
wasm-bindgen-cli alongside rust in CI so the flow is always exercised.

The wasm-bindgen library and CLI are pinned to the same wasm-bindgen
main rev (the attribute support is not yet in a release); they must
match exactly, and can move to a version pin once released.
guybedford added a commit to guybedford/emscripten that referenced this pull request Aug 7, 2026
@guybedford
Unify wasm-bindgen output under -sWASM_BINDGEN, add -sWASM_BINDGEN=auto
3aee74b 
wasm-bindgen (wasm-bindgen/wasm-bindgen#5210, updated for the __export/
__force symbol attributes from emscripten-core#27436 in wasm-bindgen/wasm-bindgen#5253)
hoists the clean exported API (functions, classes, enums) into top-level
library symbols that self-register as exports via its `--js-library`.
The user-facing API now comes from wasm-bindgen's library in every flow,
so emscripten no longer needs to guess or own the export set.

This collapses the previous staticlib-only handling into a single
-sWASM_BINDGEN path that works whether cargo/rustc drives the link (bin
crate, emcc as the linker, rustc supplies -sEXPORTED_FUNCTIONS) or emcc
drives it (staticlib, exports discovered locally):

- The exports the wasm-bindgen expansion reaches by name - the supplied
  EXPORTED_FUNCTIONS (method shims, the __wbindgen_* runtime, the marker,
  main) plus anything its expansion adds - are internal glue, not a user
  API. They are captured and kept off every export layer: the ESM wrapper
  (user_requested_exports), the factory Module attachment
  (EXPORTED_FUNCTIONS, via should_export), and the keepalive pass in
  finalize_wasm. `main` still runs automatically on init; `_main` isn't
  surfaced.
- A genuine EMSCRIPTEN_KEEPALIVE C/C++ export is not in that internal set
  and remains surfaced, so a hand-written native export composes with
  wasm-bindgen's API in the same module. Human-supplied EXPORTED_FUNCTIONS
  are not preserved through wasm-bindgen linkage yet (the rustc-supplied
  set is indistinguishable from glue); that can be revisited later.
- Strip the placeholder symbols wasm-bindgen consumes
  (__wbindgen_describe*, __externref_*, ...) so they aren't reported as
  undefined exports.
- Only run nm-based export discovery for explicit -sWASM_BINDGEN when no
  driver supplied EXPORTED_FUNCTIONS; the rustc-driven link already lists
  them exactly.
- Wire imported JS: feed library_bindgen.extern-pre.js as extern-pre-js
  and copy the snippets/ dir next to the output so relative imports
  resolve.
- The WASM_ESM_INTEGRATION wrapper re-exports the JS library symbols that
  were exported (MODULARIZE=instance), and provides wasmExports via a
  namespace import of the wasm so by-name export access works.

Add -sWASM_BINDGEN=auto: run wasm-bindgen only when the linked wasm
carries wasm-bindgen's __wasm_bindgen_emscripten_marker custom section,
which is how cargo/rustc opts in when driving emcc as the linker
(addressing the request to replace implicit marker detection with an
explicit flag); otherwise it is a no-op and wasm-bindgen need not be
installed.

Both output modes then expose only the clean API (e.g. a `Greeter`
class). Add an end-to-end test parameterized over the ESM and factory
output modes (built via cargo with -sWASM_BINDGEN=auto), a no-marker
test asserting auto is a no-op for an ordinary build, extend the
staticlib integration test to assert an EMSCRIPTEN_KEEPALIVE export
survives alongside the wasm-bindgen API, and install a pinned
wasm-bindgen-cli alongside rust in CI so the flow is always exercised.

The wasm-bindgen library and CLI are pinned to the same wasm-bindgen
main rev (the attribute support is not yet in a release); they must
match exactly, and can move to a version pin once released.
guybedford added a commit to guybedford/emscripten that referenced this pull request Aug 7, 2026
@guybedford
Unify wasm-bindgen output under -sWASM_BINDGEN, add -sWASM_BINDGEN=auto
fede9ca 
wasm-bindgen (wasm-bindgen/wasm-bindgen#5210, updated for the __export/
__force symbol attributes from emscripten-core#27436 in wasm-bindgen/wasm-bindgen#5253)
hoists the clean exported API (functions, classes, enums) into top-level
library symbols that self-register as exports via its `--js-library`.
The user-facing API now comes from wasm-bindgen's library in every flow,
so emscripten no longer needs to guess or own the export set.

This collapses the previous staticlib-only handling into a single
-sWASM_BINDGEN path that works whether cargo/rustc drives the link (bin
crate, emcc as the linker, rustc supplies -sEXPORTED_FUNCTIONS) or emcc
drives it (staticlib, exports discovered locally):

- The exports the wasm-bindgen expansion reaches by name - the supplied
  EXPORTED_FUNCTIONS (method shims, the __wbindgen_* runtime, the marker,
  main) plus anything its expansion adds - are internal glue, not a user
  API. They are captured and kept off every export layer: the ESM wrapper
  (user_requested_exports), the factory Module attachment
  (EXPORTED_FUNCTIONS, via should_export), and the keepalive pass in
  finalize_wasm. `main` still runs automatically on init; `_main` isn't
  surfaced.
- A genuine EMSCRIPTEN_KEEPALIVE C/C++ export is not in that internal set
  and remains surfaced, so a hand-written native export composes with
  wasm-bindgen's API in the same module. Human-supplied EXPORTED_FUNCTIONS
  are not preserved through wasm-bindgen linkage yet (the rustc-supplied
  set is indistinguishable from glue); that can be revisited later.
- Strip the placeholder symbols wasm-bindgen consumes
  (__wbindgen_describe*, __externref_*, ...) so they aren't reported as
  undefined exports.
- Only run nm-based export discovery for explicit -sWASM_BINDGEN when no
  driver supplied EXPORTED_FUNCTIONS; the rustc-driven link already lists
  them exactly.
- Wire imported JS: feed library_bindgen.extern-pre.js as extern-pre-js
  and copy the snippets/ dir next to the output so relative imports
  resolve.
- The WASM_ESM_INTEGRATION wrapper re-exports the JS library symbols that
  were exported (MODULARIZE=instance), and provides wasmExports via a
  namespace import of the wasm so by-name export access works.

Add -sWASM_BINDGEN=auto: run wasm-bindgen only when the linked wasm
carries wasm-bindgen's __wasm_bindgen_emscripten_marker custom section,
which is how cargo/rustc opts in when driving emcc as the linker
(addressing the request to replace implicit marker detection with an
explicit flag); otherwise it is a no-op and wasm-bindgen need not be
installed.

Both output modes then expose only the clean API (e.g. a `Greeter`
class). Add an end-to-end test parameterized over the ESM and factory
output modes (built via cargo with -sWASM_BINDGEN=auto), a no-marker
test asserting auto is a no-op for an ordinary build, extend the
staticlib integration test to assert an EMSCRIPTEN_KEEPALIVE export
survives alongside the wasm-bindgen API, and install a pinned
wasm-bindgen-cli alongside rust in CI so the flow is always exercised.

The wasm-bindgen library and CLI are pinned to the same wasm-bindgen
main rev (the attribute support is not yet in a release); they must
match exactly, and can move to a version pin once released.
guybedford added a commit to guybedford/emscripten that referenced this pull request Aug 8, 2026
@guybedford
Unify wasm-bindgen output under -sWASM_BINDGEN, add -sWASM_BINDGEN=auto
2d5101f 
wasm-bindgen (wasm-bindgen/wasm-bindgen#5210, updated for the __export/
__force symbol attributes from emscripten-core#27436 in wasm-bindgen/wasm-bindgen#5253)
hoists the clean exported API (functions, classes, enums) into top-level
library symbols that self-register as exports via its `--js-library`.
The user-facing API now comes from wasm-bindgen's library in every flow,
so emscripten no longer needs to guess or own the export set.

This collapses the previous staticlib-only handling into a single
-sWASM_BINDGEN path that works whether cargo/rustc drives the link (bin
crate, emcc as the linker, rustc supplies -sEXPORTED_FUNCTIONS) or emcc
drives it (staticlib, exports discovered locally):

- The exports the wasm-bindgen expansion reaches by name - the supplied
  EXPORTED_FUNCTIONS (method shims, the __wbindgen_* runtime, the marker,
  main) plus anything its expansion adds - are internal glue, not a user
  API. They are captured and kept off every export layer: the ESM wrapper
  (user_requested_exports), the factory Module attachment
  (EXPORTED_FUNCTIONS, via should_export), and the keepalive pass in
  finalize_wasm. `main` still runs automatically on init; `_main` isn't
  surfaced.
- A genuine EMSCRIPTEN_KEEPALIVE C/C++ export is not in that internal set
  and remains surfaced, so a hand-written native export composes with
  wasm-bindgen's API in the same module. Human-supplied EXPORTED_FUNCTIONS
  are not preserved through wasm-bindgen linkage yet (the rustc-supplied
  set is indistinguishable from glue); that can be revisited later.
- Strip the placeholder symbols wasm-bindgen consumes
  (__wbindgen_describe*, __externref_*, ...) so they aren't reported as
  undefined exports.
- Only run nm-based export discovery for explicit -sWASM_BINDGEN when no
  driver supplied EXPORTED_FUNCTIONS; the rustc-driven link already lists
  them exactly.
- Wire imported JS: feed library_bindgen.extern-pre.js as extern-pre-js
  and copy the snippets/ dir next to the output so relative imports
  resolve.
- The WASM_ESM_INTEGRATION wrapper re-exports the JS library symbols that
  were exported (MODULARIZE=instance), and provides wasmExports via a
  namespace import of the wasm so by-name export access works.

Add -sWASM_BINDGEN=auto: run wasm-bindgen only when the linked wasm
carries wasm-bindgen's __wasm_bindgen_emscripten_marker custom section,
which is how cargo/rustc opts in when driving emcc as the linker
(addressing the request to replace implicit marker detection with an
explicit flag); otherwise it is a no-op and wasm-bindgen need not be
installed.

Both output modes then expose only the clean API (e.g. a `Greeter`
class). Add an end-to-end test parameterized over the ESM and factory
output modes (built via cargo with -sWASM_BINDGEN=auto), a no-marker
test asserting auto is a no-op for an ordinary build, extend the
staticlib integration test to assert an EMSCRIPTEN_KEEPALIVE export
survives alongside the wasm-bindgen API, and install a pinned
wasm-bindgen-cli alongside rust in CI so the flow is always exercised.

The wasm-bindgen library and CLI are pinned to the same wasm-bindgen
main rev (the attribute support is not yet in a release); they must
match exactly, and can move to a version pin once released.
guybedford added a commit to guybedford/emscripten that referenced this pull request Aug 8, 2026
@guybedford
Unify wasm-bindgen output under -sWASM_BINDGEN, add -sWASM_BINDGEN=auto
538e1fb 
wasm-bindgen (wasm-bindgen/wasm-bindgen#5210, updated for the __export/
__force symbol attributes from emscripten-core#27436 in wasm-bindgen/wasm-bindgen#5253)
hoists the clean exported API (functions, classes, enums) into top-level
library symbols that self-register as exports via its `--js-library`.
The user-facing API now comes from wasm-bindgen's library in every flow,
so emscripten no longer needs to guess or own the export set.

This collapses the previous staticlib-only handling into a single
-sWASM_BINDGEN path that works whether cargo/rustc drives the link (bin
crate, emcc as the linker, rustc supplies -sEXPORTED_FUNCTIONS) or emcc
drives it (staticlib, exports discovered locally):

- The exports the wasm-bindgen expansion reaches by name - the supplied
  EXPORTED_FUNCTIONS (method shims, the __wbindgen_* runtime, the marker,
  main) plus anything its expansion adds - are internal glue, not a user
  API. They are captured and kept off every export layer: the ESM wrapper
  (user_requested_exports), the factory Module attachment
  (EXPORTED_FUNCTIONS, via should_export), and the keepalive pass in
  finalize_wasm. `main` still runs automatically on init; `_main` isn't
  surfaced.
- A genuine EMSCRIPTEN_KEEPALIVE C/C++ export is not in that internal set
  and remains surfaced, so a hand-written native export composes with
  wasm-bindgen's API in the same module. Human-supplied EXPORTED_FUNCTIONS
  are not preserved through wasm-bindgen linkage yet (the rustc-supplied
  set is indistinguishable from glue); that can be revisited later.
- Strip the placeholder symbols wasm-bindgen consumes
  (__wbindgen_describe*, __externref_*, ...) so they aren't reported as
  undefined exports.
- Only run nm-based export discovery for explicit -sWASM_BINDGEN when no
  driver supplied EXPORTED_FUNCTIONS; the rustc-driven link already lists
  them exactly.
- Wire imported JS: feed library_bindgen.extern-pre.js as extern-pre-js
  and copy the snippets/ dir next to the output so relative imports
  resolve.
- The WASM_ESM_INTEGRATION wrapper re-exports the JS library symbols that
  were exported (MODULARIZE=instance), and provides wasmExports via a
  namespace import of the wasm so by-name export access works.

Add -sWASM_BINDGEN=auto: run wasm-bindgen only when the linked wasm
carries wasm-bindgen's __wasm_bindgen_emscripten_marker custom section,
which is how cargo/rustc opts in when driving emcc as the linker
(addressing the request to replace implicit marker detection with an
explicit flag); otherwise it is a no-op and wasm-bindgen need not be
installed.

Both output modes then expose only the clean API (e.g. a `Greeter`
class). Add an end-to-end test parameterized over the ESM and factory
output modes (built via cargo with -sWASM_BINDGEN=auto), a no-marker
test asserting auto is a no-op for an ordinary build, extend the
staticlib integration test to assert an EMSCRIPTEN_KEEPALIVE export
survives alongside the wasm-bindgen API, and install a pinned
wasm-bindgen-cli alongside rust in CI so the flow is always exercised.

The wasm-bindgen library and CLI are pinned to the same wasm-bindgen
main rev (the attribute support is not yet in a release); they must
match exactly, and can move to a version pin once released.
guybedford added a commit to guybedford/emscripten that referenced this pull request Aug 8, 2026
@guybedford
Unify wasm-bindgen output under -sWASM_BINDGEN, add -sWASM_BINDGEN=auto
5d82a9d 
wasm-bindgen (wasm-bindgen/wasm-bindgen#5210, updated for the __export/
__force symbol attributes from emscripten-core#27436 in wasm-bindgen/wasm-bindgen#5253)
hoists the clean exported API (functions, classes, enums) into top-level
library symbols that self-register as exports via its `--js-library`.
The user-facing API now comes from wasm-bindgen's library in every flow,
so emscripten no longer needs to guess or own the export set.

This collapses the previous staticlib-only handling into a single
-sWASM_BINDGEN path that works whether cargo/rustc drives the link (bin
crate, emcc as the linker, rustc supplies -sEXPORTED_FUNCTIONS) or emcc
drives it (staticlib, exports discovered locally):

- The exports the wasm-bindgen expansion reaches by name - the supplied
  EXPORTED_FUNCTIONS (method shims, the __wbindgen_* runtime, the marker,
  main) plus anything its expansion adds - are internal glue, not a user
  API. They are captured and kept off every export layer: the ESM wrapper
  (user_requested_exports), the factory Module attachment
  (EXPORTED_FUNCTIONS, via should_export), and the keepalive pass in
  finalize_wasm. `main` still runs automatically on init; `_main` isn't
  surfaced.
- A genuine EMSCRIPTEN_KEEPALIVE C/C++ export is not in that internal set
  and remains surfaced, so a hand-written native export composes with
  wasm-bindgen's API in the same module. Human-supplied EXPORTED_FUNCTIONS
  are not preserved through wasm-bindgen linkage yet (the rustc-supplied
  set is indistinguishable from glue); that can be revisited later.
- Strip the placeholder symbols wasm-bindgen consumes
  (__wbindgen_describe*, __externref_*, ...) so they aren't reported as
  undefined exports.
- Only run nm-based export discovery for explicit -sWASM_BINDGEN when no
  driver supplied EXPORTED_FUNCTIONS; the rustc-driven link already lists
  them exactly.
- Wire imported JS: feed library_bindgen.extern-pre.js as extern-pre-js
  and copy the snippets/ dir next to the output so relative imports
  resolve.
- The WASM_ESM_INTEGRATION wrapper re-exports the JS library symbols that
  were exported (MODULARIZE=instance), and provides wasmExports via a
  namespace import of the wasm so by-name export access works.

Add -sWASM_BINDGEN=auto: run wasm-bindgen only when the linked wasm
carries wasm-bindgen's __wasm_bindgen_emscripten_marker custom section,
which is how cargo/rustc opts in when driving emcc as the linker
(addressing the request to replace implicit marker detection with an
explicit flag); otherwise it is a no-op and wasm-bindgen need not be
installed.

Both output modes then expose only the clean API (e.g. a `Greeter`
class). Add an end-to-end test parameterized over the ESM and factory
output modes (built via cargo with -sWASM_BINDGEN=auto), a no-marker
test asserting auto is a no-op for an ordinary build, extend the
staticlib integration test to assert an EMSCRIPTEN_KEEPALIVE export
survives alongside the wasm-bindgen API, and install a pinned
wasm-bindgen-cli alongside rust in CI so the flow is always exercised.

The wasm-bindgen library and CLI are pinned to the same wasm-bindgen
main rev (the attribute support is not yet in a release); they must
match exactly, and can move to a version pin once released.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@sbc100 sbc100 sbc100 approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@guybedford @sbc100